[Chapter 35] 35.10 Alphabetized Reference
Author: Bryan Costales & Eric Allman
Date: 1999-01-06T21:53:09Z

#

| Chapter 35 Headers |

## 35.10 Alphabetized Reference

Some header lines need to be declared in the configuration file by using the `H` command. Others are created internally by sendmail. Still others are created by mail MUAs. These differences are described individually with each header-line `name`. The following discussion of header names is in alphabetical order.

### 35.10.1 Apparently-From:

The unknown sender

(Smail)

> The Smail 3.x program (a UUCP-oriented replacement for sendmail) produces an `Apparently-From:` header when it is unable to find any of the official sender headers in a mail message. The address that it provides to this nonstandard header is taken from the envelope of the message.

> The sendmail program, on the other hand, places the envelope sender into a `From:` header in this situation. If there is no envelope sender and if the sender was not specified in the command line, sendmail sets the sender to be postmaster.

> The `Apparently-From:` header is mentioned here only because it may appear in messages received at sites that run sendmail. It shouldn't cause problems, because a good sender address still appears in the SMTP envelope.

> The `Apparently-From:` header should never be declared in the configuration file and should not be added to conf.c.

### 35.10.2 Apparently-To:

When the message lacks a recipient

(sendmail)

> If the header of a mail message lacks recipient information (lacks all of the `To:`, `Cc:`, and `Bcc`: header lines), sendmail adds an `Apparently-To:` header line and puts the recipient's address from the envelope into the field of that line. This behavior is hard-coded into pre-8.7 sendmail, but beginning with version 8.7, it can be tuned with the `NoRecipientAction` option (see Section 34.8.43).

> The `Apparently-To:` header name is not defined in RFC822. It is added by pre-8.7 sendmail because RFC822 requires at least one `To:` or `Cc:` header, and neither is present.

> An `Apparently-To:` header should never be defined in the configuration file.

### 35.10.3 Auto-Submitted:

Why the bounce

(sendmail)

> When a message is returned because of an error or because a "return receipt" was requested, V8 sendmail adds an `Auto-Submitted:` header. This header describes the reason for the return:

> >     Auto-Submitted: auto-generated (reason)

> The reason can be one of four things: It can be `warning-timeout` if the message has reached its `Timeout.queuewarn` option threshold (see Section 34.8.70, Timeout (r)). It can be `postmaster-warning` if the failure was delivered to the postmaster as a result of a problem that the postmaster should fix, such as an MX configuration error. It can be `return-receipt` if the message was returned because of a `Return-Receipt-To:` header (see Section 35.10.29) or a DSN NOTIFY=SUCCESS request (see RFC1891). Finally, it can be `failure` for any other reason.

> In all instances, sendmail also adds a `Subject:` header that contains the actual text that led to the bounce or return. This text is identical to that saved in the `qf` file's `M` line (see Section 23.9.9, M line).

> The `Auto-Submitted:` header should never be defined in the configuration file.

### 35.10.4 Bcc:

Blind carbon copy

(RFC822)

> A blind carbon copy is a copy of the mail message that is sent to one or more recipients without the knowledge of the primary recipients. Primary recipients are listed in the `To:` and `Cc:` lines. When there are multiple blind carbon copy recipients, knowledge of each other is also hidden.

> When run with a `-t` command-line switch (to gather recipients from the headers), the sendmail program achieves this end by saving a list of all the blind carbon copy recipients, deleting the `Bcc:` header line, and then delivering to each blind carbon copy recipient. (See the `Apparently-To:` header.)

> The `Bcc:` header should never be declared in the configuration file.

> The field for the `Bcc:` header must contain one or more properly formed addresses. Where there is more than one, each should be separated from the others by commas.

### 35.10.5 Cc:

Carbon copy

(RFC822)

> The `Cc:` header is one of a few that specify the list of primary recipients. The sendmail program treats the `Cc:` header no differently from the way it treats the `To:` header. From the user's point of view, the `Cc:` header implies that there are recipients to whom an informational copy of the message was supplied.

> The `Cc:` header should never be declared in the configuration file.

> The field for the `Cc:` header must contain one or more properly formed addresses.

### 35.10.6 Comments:

Header commentary

(RFC822)

> The `Comments:` header is used to place explanatory text into the header portion of an email. The field portion of the `Comments:` header may contain arbitrary text.

> One possible use for a `Comments:` header would be to notify recipients that one person is replying to mail for another:

> >     Comments: Ben is in France for the next month or
> >               so gathering information for the meeting.
> >               I am handling his mail while he is away.

> >        whitespace

> The `Comments:` header should rarely be declared in the configuration file. If it is, it should be prefixed with appropriate `?``flags``?`. For example,

> >     H?B?Comments: Local delivery is experimentally being handled
> >            by a new program. Complaints to root.

> This comment is included only in headers that are delivered via the `local` delivery agent, because that delivery agent is the only one to include the `F=B` flag:

> >     Mlocal, P=/bin/mail, F=rlsDFMmnPB, S=10, R=20, A=mail -d $u

> For all versions of sendmail except V8, if there is already a `Comments:` header in the message, this configuration-file declaration is ignored. For V8 sendmail this declaration will always cause the new `Comment:` header to be added to the mail message.

### 35.10.7 Content-Length:

The size of the body of the message

(System V Release 4)

> The `Content-Length:` header describes the approximate size of the body of a message. The size is always a decimal expression of the number of bytes occupied by the body.

> >     Content-Length: 5678

> It is used by some MUAs to find a message faster in a large file of many messages. It is always created or added by MUAs or delivery agents and never by MTAs. It should never be declared in the configuration file.

> For Sun's version of V8 sendmail the behavior of the `Content-Length:` can be traced with the `-d80` debugging switch (see Section 37.5.190, -d80.1). All other versions of sendmail ignore this header.

### 35.10.8 Content-Transfer-Encoding:

Auxiliary MIME encoding used in the message

(RFC1521)

> The MIME `Content-Transfer-Encoding:` header describes what auxiliary encoding was applied to the message body to allow it to pass through email transport mechanisms that may have data or character set limitations. Specifically, RFC821 requires message bodies to contain only 7-bit data. To transport 8-bit data (such as images and sounds) via SMTP, it is necessary to convert that data to 7 bits. The `Content-Transfer-Encoding:` header specifies precisely how that conversion was done:

> >     Content-Transfer-Encoding: how

> Here, how is defined by RFC821 to be one of the following: `base64` (see RFC1521), `quoted-printable` (see Section 34.8.22, EightBitMode (8)), `8bit` (meaning that the message body contains unencoded 8-bit data in line length suitable for SMTP transport), `7bit` (the message body contains 7-bit, SMTP-compliant data), or `binary` (the message body contains 8-bit data in a form that is completely unsuitable for SMTP transport).

> See the `EightBitMode` (`8`) option (see Section 34.8.22) for a description of how V8 sendmail converts between 8- and 7-bit data. The `Content-Transfer-Encoding:` header should never be declared in the configuration file.

### 35.10.9 Content-Type:

The nature of the body of the message

(RFC1521)

> The `Content-Type:` header describes the nature of the body of a mail message. In the absence of such a header, the body is presumed to be composed of ASCII characters that have their high (most significant) bits turned off. One possible setting for this header might look like this:

> >     Content-Type: text/plain; charset=ISO-8859-1

> This header says that the body uses the ISO-8859-1 character set.

> This header is usually created by the originating MUA. It should never be declared in the configuration file of pre-V8.7 versions of sendmail. Beginning with V8.7, the content type for 8- to 7-bit MIME conversions can be declared with the `DefaultCharSet` option (Section 34.8.14, DefaultCharSet).

> When bouncing mail, V8 sendmail creates a MIME-compliant message and includes a `Content-Type:` header like this:

> >     Content-Type: multipart/mixed; boundary="boundary"

> If sendmail was compiled to include DSN support (see Section 18.8.5, DSN), the `Content-Type:` header will look like this:

> >     Content-Type: multipart/report; report-type=delivery-status;
> >             boundary="boundary"

### 35.10.10 Date:

The origin date

(RFC822)

> The `Date:` header specifies the date and time that the mail message was originally sent. All mail messages must include this header line. Consequently, the `Date:` header must be declared in the configuration file like this:

> >     H?D?Date: $a

> The `$a` macro (see Section 31.10.2, $a) is mandatory in the field for this header. The value in `$a` is the current time in RFC822 format. (See Section 5.1 in RFC822 and Section 5.2.14 in RFC1123.) Only the `$a` macro should be used with the `Date:` header, because it is the only one that is guaranteed to contain the current date and time in RFC822 (and RFC1123) format.

> The `?D?` flag is always included with the `Date:` declaration in the configuration file. All the standard delivery agents always include a `F=D` flag (see Section 30.8.17, F=D). The `?D?` allows custom delivery agents to be designed that do not need a `Date:` header.

### 35.10.11 Delivered-To:

Mark a mailing list expansion

(qmail)

> The qmail program uses a `Delivered-To:` header to trace all the alias and mailing list expansions through which an email message passes. This is similar to the way `Received:` headers are used to trace machine hops. When qmail expands a mailing list, it adds a `Delivered-To:` header to the top of the message:

> >     Delivered-To: list@host

> If an identical header is already present, qmail bounces the message. This prevents several kinds of mail loops. (Note that the SmartList program supports an `X-Loop:` header with the same function.)

> This technique is further described in the following draft document:

> > ftp://koobera.math.uic.edu/pub/docs/RFCLOOPS

> The `Delivered-To:` header should never be declared in the configuration file.

### 35.10.12 Encrypted:

Message is transformed

(RFC822)

> The `Encrypted:` header is used to describe a translation that has been performed on the body of the mail message. Although encryption is implied, other forms of translation, such as compression and uuencode(1), are perfectly legal.

> The sendmail program ignores the `Encrypted:` header. This header is intended for use by MUAs. Unfortunately, most (if not all) UNIX MUAs also ignore this header. The form for the `Encrypted:` header is:

> >     Encrypted: prog key

> The field contains one mandatory item, the `prog`, and one optional item, the `key`. The `prog` is the name of the program that was used to transform the message body. The optional `key` is a decryption key.

> If translating the message body into a different form, be aware that many versions of sendmail strip the eighth bit from all bytes of the body during transmission.

> The `Encrypted:` header should never be declared in the configuration file.

### 35.10.13 Errors-To:

Error notification redirect

(sendmail)

> Ordinarily, errors are bounced to the envelope sender. The `Errors-To:` header specifies the address, or addresses, to which sendmail should send additional notification of delivery errors.

> The `Errors-To:` header is intended for use by mailing lists to prevent errors in a list from being rebroadcast to the list as a whole. For example, consider the mailing list allusers. Mail that is sent to this list should contain the following header lines:

> >     To: allusers
> >     From: allusers-submit
> >     Errors-To: allusers-errors

> The `From:` header allows reply mail to be submitted for distribution to the list. The `Errors-To:` header causes error notification to be sent to `allusers-errors` so that the maintainer can fix any errors in the list. The original sender also gets error notification unless the mailing list software represents the maintainer in the envelope (see Section 25.5.1, "Reply Versus Bounce").

> Under SunOS and V8 sendmail the `Errors-To:` is flagged in conf.c with the H_ERRSTO header flag (see Section 35.5.11). This allows other headers to be declared in that file as error redirect headers. Under pre-V8 SunOS sendmail the `Errors-To:` header is ignored if the error mode set by the `e` option is `m` (see Section 34.8.24.2, "ErrorMode=m").

> Under V8 sendmail the `Errors-To:` header is ignored unless the `UseErrorsTo` (`l`) option (see Section 34.8.74) is true. It does this because the `Errors-To:` header violates RFC1123. `Errors-To:` was needed only to take the place of the envelope sender in the days when most UNIX delivery agents couldn't differentiate between header and envelope.

> The `Errors-To:` header should never be declared in the configuration file.

### 35.10.14 From:

The sender

(RFC822)

> The `From:` header lists the address of the sender. There are only four legal forms that the field of this header can take:

> >     From: address
> >     From: <address>
> >     From: Full Name <address>
> >     From: address (comment)

> A `From:` header must be declared in the configuration file, and its field is composed of the `$x` (see Section 31.10.42) and `$g` (see Section 31.10.16, $g) macros. For example,

> >     H?F?From: $?x$x <$g>$|$g$.

> `$g` contains the official return address of the sender. `$x` contains the full name for the sender. `$x` may be undefined for some addresses, so it should be wrapped in the `$?` and `$.` conditional operators (see Section 31.6).

> The `From:` header must be prefixed by the `?F?` flag because all the traditional delivery agents use the `F=F` flag (see Section 30.8.21, F=F) to force inclusion of that header. Use of the `?F?` flag allows new delivery agents to be written that don't require the `From:` header. The `resent-` form of the `From:` header must also be declared in the configuration file:

> >     H?F?Resent-From: $?x$x <$g>$|$g$.

> This ensures that every mail message has a sender, even if the mail message has been forwarded.

> Note that sendmail does not add the `From:` header or its `resent-` form if a `From:` header already exists in the header portion of the mail message. A possible exception occurs if the envelope sender is identical to the address in the `From:` header. In that instance, the `From:` header is discarded and a new one is created (see Section 35.7.1, "Remove and Recreate the From: Header").

### 35.10.15 Full-Name:

The sender's full name

(sendmail)

> The `Full-Name:` header is used to list the sender's full name if it is known. The field for this header may be arbitrary text but is usually the value in the `$x` macro (see Section 31.10.42):

> >     H?x?Full-Name: $x
> >     H?x?Full-Name: (User names hidden for security)

> The `Full-Name:` header should be prefixed with the `?x?` flag so that selected delivery agents may require inclusion of that header. This header definition is usually meaningless, because all traditional delivery agents omit the `F=x` flag. It can be useful, however, for mailing through sites that strip or destroy `From:` headers.

> The `Full-Name:` header may be specified in the configuration file. If this header is already in the mail message, sendmail does not replace it. But note that V8 sendmail will remove the `Full-Name:` header if the `F=x` flag (see Section 30.8.44, F=x) is set for the recipient's delivery agent.

### 35.10.16 In-Reply-To:

Identify previous correspondence

(RFC822)

> The `In-Reply-To:` header is used to identify previous correspondence that the current message is in reply to. This header is generated by MUAs, not by sendmail. The field for this header is arbitrary text with one restriction. If that text includes the message identifier, that identifier must be enclosed in angle brackets (`<` and `>`) and must adhere to the format for all message identifiers. Note that the message identifier should be included but is not required.

> A typical use of the `In-Reply-To:` header might look like the following:

> >     In-Reply-To: Your message of Fri, 13 Dec 1996 05:47:44 -0700
> >            The subject of which was: "Which came first?"

> >        whitespace

> The `In-Reply-To:` header should never be declared in the configuration file.

### 35.10.17 Keywords:

Index to contents

(RFC822)

> The `Keywords:` header is used to list significant words from the body of the mail message that aid in the indexing of its contents. This header is never added by sendmail. Although some user mail-reading programs can create this header, it is usually created by Usenet news-posting programs.

> The field for the `Keywords:` header is arbitrary text. This header should never be declared in the sendmail configuration file.

### 35.10.18 Mail-From:

Synonym for Received:

(obsolete)

> The `Mail-From:` header is not defined by any of the RFCs and is rarely seen in message headers. The sendmail program defines it internally as a synonym for the `Received:` header. The `Mail-From:` header is obsolete.

### 35.10.19 Message-ID:

Unique identifier for message

(RFC822)

> The `Message-ID:` header is used to uniquely identify each mail message. This header must be declared in the configuration file. The field for this header must be an expression in the form of a legal address enclosed in angle brackets (`<` and `>`). The address must be composed of elements that create an identifier that is truly unique worldwide. The `Message-ID:` header is declared in the configuration file:

> >     ?M?Message-Id: <$t.$i@$j>

> Here, the field is an address of the form `user@domain`, which is enclosed in angle brackets. The `$t` macro (see Section 31.10.35, $t) is an integer representation of the current time to the nearest second. The `$i` macro (see Section 31.10.19, $i) is the unique queue identifier that is used to identify this message locally. The `$j` macro (see Section 31.10.20, $j) is the fully qualified domain name of the local host. The `Message-ID:` header as it might appear in an actual mail message would look like this:

> >     Message-Id: <9207100411.AA14505@nic.cerf.net>

> The `Message-ID:` header should be prefixed with a `?M?` flag so that it is inserted only into headers of messages whose delivery agents have the `F=M` flag set. The standard delivery agents include this flag.

> The `resent-` form of the `Message-ID:` header must also be declared in the configuration file:

> >     ?M?Resent-Message-Id: <$t.$i@$j>

> This ensures that every mail message has a message identifier even if the message is forwarded.

> Note that sendmail does not add a `Message-ID:` header or its `Resent-` form if a `Message-ID:` header already exists in the header portion of a mail message. Furthermore, the `Resent-` form is added only if sendmail determines that the message is a resent message.

> Also note that you should never try to replace an existing `Message-ID:` header with one of your own. This could result in the loss of important information needed to trace the origin of a message.

### 35.10.20 Message:

Marks end of headers

(sendmail)

> The `Message:` header is used to mark an early end to a mail message's headers. When sendmail finds this header, it immediately stops gathering the message's header lines and treats the rest of the header as the start of the message body. This header is useful for including non-Internet headers in the header portion of a mail message. For example,

> >     To: george@wash.dc.gov (George Washington)
> >     Subject: Re: More text
> >     Date: Tue, 04 Aug 92 14:14:56 -0400
> >     Message-Id: <31842.AA01513@wash.dc.gov>
> >     Received: by wash.dc.gov (4.1/1.12 $)
> >             id AA01513; Tue, 4 Aug 92 12:15:01 PDT
> >     From: Ben Franklin <ben@philly.dc.gov>
> >     Message:
> >     ROUTED BY BITNET\/CO=US/ROUTE=INTERNET/
> >     FORMAT OF MESSAGE /LANG=USENGLISH/FORM=PLAINTEXT/

> Here, the last two header lines are non-Internet headers that may confuse some programs. But the `Message:` header that precedes them tells sendmail to treat them as message body, and problems are avoided.

> Note that `Message:` is not defined by any RFC but is a convention that is shared by all versions of sendmail and most other MTAs. The `Message:` header should never be declared in the configuration file.

### 35.10.21 MIME-Version:

Notify that error return contains MIME support

(RFC1521)

> MIME (Multipurpose Internet Mail Extensions) is documented in RFC1521, with additional details in RFC1344, RFC1426, RFC1428, and RFC1437. The sendmail program cares about MIME only when bouncing messages and when determining how to convert the message body between 8 and 7 bits. If the `SendMimeErrors` (`j`) option (see Section 34.8.60, SendMimeErrors (j)) is set, V8 sendmail includes the following header in all returned (bounced) mail:

> >     MIME-Version: 1.0

> This is hard-coded into sendmail. See the `SendMimeErrors` (`j`) option for further details about this header.

> The `MIME-Version:` header should never be declared in the configuration file.

### 35.10.22 Posted-Date:

Date submitted

(sendmail)

> The `Posted-Date:` header is used by some old Usenet news software and some mailing list software to indicate the date and time that a mail message was posted (submitted for distribution). The `Date:` header, on the other hand, shows when the message was mailed. In actual practice, the two usually show the same date and time.

> When sendmail tries to determine the originating date of a mail message, it first looks for a `Posted-Date:` header. If one is found, it uses that date. Otherwise, it uses the date from the `Date:` header. Whichever is used, the result is stored into the `$a` macro (see Section 31.10.2).

> The `Posted-Date:` header is not a part of the RFC822 standard, so it should not be declared in the sendmail configuration file.

### 35.10.23 Precedence:

Set ordering in queue

(sendmail)

> The `Precedence:` header is used internally by sendmail to order the processing of messages in its queue. A full description of the possible field values for this header is given in Section 35.8.1, "The P Configuration Command". The effect of those values on ordering the queue is described in Section 23.5, "How the Queue Is Processed".

> The `Precedence:` header should never be declared as an `H` line in the configuration file. However, `P` precedence lines should be declared in that file.

### 35.10.24 Priority:

Determine timeouts in the queue

(sendmail)

> Mail messages may be placed into the queue either intentionally or because they could not be delivered immediately. Once they are in the queue, two time periods come into play. First is the period of time that the message should remain in the queue before a warning is issued to the sender. Second is the total period of time that the message should remain in the queue before it is bounced as a failed message.

> Beginning with V8.7 sendmail, it is now possible to tailor these intervals on the basis of three distinct priorities of mail. The new `Priority:` header tells sendmail which priority a message possesses:

> >     Priority: pri

> Here, `pri` can have one of three possible values: `urgent`, `normal`, and `non-urgent`. These values correspond directly to the priorities specified by the `Timeout.queuewarn` option (see Section 34.8.70.15, "Timeout.queuewarn") and `Timeout.queuereturn` option (see Section 34.8.70.14, "Timeout.queuereturn"):

> >     O Timeout.queuereturn.urgent=1d
> >     O Timeout.queuereturn.normal=2d
> >     O Timeout.queuereturn.non-urgent=4d

> Here, a `Priority:` header of `normal` will cause the message containing it to bounce after it has remained in the queue for two days.

> The `Priority:` header should never be declared in the configuration file.

### 35.10.25 Received:

Trace routing of mail

(RFC822)

> The `Received:` header is used to record information about each and every site a mail message passes through on its way to ultimate delivery. First this header is inserted by the original sending site, then another is added by each site that the message passes through, including the site performing final delivery. Each new header is added to the top of the list of `Received:` headers, forming a chronological record (reading bottom up through the headers) of how the mail message was handled.

> The contents of the `Received:` header's field is narrowly defined by RFC822. Its defined form looks like this:

> >     Received: ["from" host] "by" host ["via" atom] ["with" atom]
> >            "id" string ["for" addr] ";" date

> >        whitespace

> The field is composed of six items that may be split over multiple lines by using whitespace to indent the second. Items that are optional are enclosed in square brackets. Each item is composed of two parts a word (shown in quotation marks) and a value. All, or only the few required items, need to be present. When they are present, they must be in the following order:

> `from`

>   Full canonical name of the sending host (if available)

> `by`

>   Full canonical name of the receiving host (required)

> `via`

>   Physical network that was used to transmit the message, such as INTERNET, JANET, or XNS (optional)

> `with`

>   Protocol used to receive the message, such as SMTP (optional)

> `id`

>   Unique queue identifier assigned by the local host (required)

> `for`

>   Initial, untranslated address of the recipient (seldom used)

> `;date`

>   Date this message was received (required)

> The `Received:` header must be declared in the configuration file. It is a mandatory header, so it should never be prefixed with `?``flags``?`. A typical declaration of this header would look like this:

> >     HReceived: $?sfrom $s $.$?_($?s$|from $.$_) $.by $j ($v/$Z)$?r with $r$.
> >             id $i$?u for $u$.; $b

> Here, seven items are included in the field:

> `$?from $s $.`

>   If the `$s` macro contains a value, the word `from` and that value are inserted into the header. The `$s` macro (see Section 31.10.33, $s) contains the full canonical name of the sender's host.

> `$?_($?s$|from $.$_) $.`

>   This is a nested conditional. If the `$_` macro contains a value, the parentheses and all the information inside them are inserted into the header. If the `$_` macro lacks a value, nothing is inserted into the header.

>   Inside the parentheses the value of `$_` is inserted into the header. Another conditional expression determines if the `$_` just inserted should also be prefixed with the word `from`. If the `$s` macro lacks a value the word `from` is inserted in front of the `$_`. The `$_` macro contains the RFC1413 identd(8) identity of the connecting host and any IP routing information (see Section 31.10.1, $-).

> `by $j ($v/$Z)`

>   The `$j` macro contains the full canonical name of the local host. The parentheses surround a comment that is formed from `$v` (see Section 31.10.38, $v), the version of the sendmail program, and `$Z` (see Section 31.10.47, $Z) the version of the configuration file.

> `$?r with $r$.`

>   If the `$r` macro contains a value, the word `with` followed by the value of `$r` is inserted into the header. The `$r` macro (see Section 31.10.31, $r) contains a string that indicates the protocol used to receive the message (such as SMTP or ESMTP).

> `id` `$i`

>   The `$i` macro contains the identifier created by sendmail to uniquely identify this mail message at this host (see Section 31.10.19).

> `$?u for $u$`

>   If the `$u` macro contains a value, the word `for` followed by the value of `$u` is inserted into the header. The `$u` macro (see Section 31.10.36, $u) contains the recipient's username.

> `;` `$b`

>   The `$b` macro contains the current date and time in RFC822 format (see Section 31.10.3, $b).

> The `Received:` declaration shown above is the one typically used by most sites running V8 sendmail.

### 35.10.26 References:

Reference to original message

(RFC822)

> The `References:` header is used by mail-reading programs to include a reference to the original message in replies. Although this header may legally contain arbitrary text as its field, it usually contains a copy of the original `Message-ID:` header field.

> The `References:` header typically looks something like this:

> >     References: <9205041920.AA27932@wash.dc.gov>

> Notice that the message identifier is wrapped in angle brackets, which cause it to look like an address.

> The `References:` header should never be declared in the configuration file.

### 35.10.27 Reply-To:

Alternative reply address

(RFC822)

> The `Reply-To:` header requests that replies to messages go to one or more addresses that are different from that of the original sender. This header is usually inserted by mailing-list software, where the `From:` is the address of the mailing list and the `Reply-To:` is the address of the list's maintainer.

> The field for the `Reply-To:` header must obey the same rules as those for the `From:` header's field. One example of the use of this header might look like this:

> >     From: mailinglist@list.server.com
> >     Reply-To: mailinglist-request@list.server.com

> The `-request` suffix is used by many mailing lists to specify the list maintainer.

> The `Reply-To:` header should never be declared in the configuration file.

### 35.10.28 Return-Path:

Return address of sender

(RFC822)

> The `Return-Path:` header is intended to show the envelope address of the real sender as opposed to the sender used for replying (the `From:` and `Reply-To:` headers). In posting Usenet news, for example, the `Return-Path:` shows "news" and the `From:` shows the address of the posting user. But in general, `Return-Path:` should never be used for replying to mail. It is intended to be used solely for notification of delivery errors.

> There must be only one `Return-Path:` header in any mail message, and it should be placed there by the site performing final delivery. This header should be declared in the configuration file like this:

> >     H?P?Return-Path: <$g>

> The `?P?` flag ensures that only delivery agents that perform final delivery insert this header. Those delivery agents are usually `prog` and `local`, which usually contain an `F=P` delivery agent flag.

> The `$g` macro (see Section 31.10.16) contains as its value the address of the sender relative to the recipient.

> Unfortunately, two circumstances can cause the `Return-Path:` header to contain incorrect information. First, the message may arrive at your site with that header already there. If this happens, there is usually no way to get rid of it, because most versions of sendmail lack a conf.c `H_` flag that means to replace an existing header. However, with V8 sendmail, defining H_ACHECK (see Section 35.5.16) in conf.c causes a header to be replaced even if one is already in the message.

> The second problem stems from the fact that final delivery may not really be final. The `local` delivery agent program may be something like procmail(8), which allows mail to appear to be locally delivered, while also allowing users to run shell scripts that may forward their mail to another site.

> To minimize these problems, always declare the `Return-Path:` header with the proper `?``flags``?` in the configuration file. Doing this ensures that it will be inserted when legal and that the address your site places in it is usually correct.

### 35.10.29 Return-Receipt-To:

Verify delivery

(sendmail prior to V8.7)

> he `Return-Receipt-To:` header causes sendmail to send a mail message back to the specified recipient confirming final delivery. It is no longer supported as of V8.7 sendmail (instead, see NOTIFY=SUCCESS in Section 36.7.28, -N). [4] If a pre-8.7 version of sendmail finds this header when it is processing mail for delivery, and if the selected delivery agent has the `F=l` flag set, sendmail creates a bounced mail message. The recipient is set to the person specified in the `Return-Receipt-To:` header, and the following subject header line is included:

> > [4] `Return-Receipt-To:` was a bad idea. It gave false information (such as the suggestion that a user who never reads mail accepted delivery). It can wrongly propagate (as, for example, when a mailing list gets the receipt instead of you). And it is insecure (a nasty person can use it to find "hidden" members of a mailing list).

> >     Subject: Returned Mail: Return Receipt      prior to V8.7
> >     Subject: Return Receipt                     starting with V8.7

> The message appears to originate from the user defined by the `$n` macro (see Section 31.10.26, $n), and contains a copy of the original header as its body.

> The `Return-Receipt-To:` header should never be declared in the configuration file and, in fact, should rarely be used at all. It is not intended as a routine delivery-verification mechanism but rather is intended for occasional use in debugging delivery problems. It is especially dangerous when used in outgoing mailing-list mail, because it can cause an avalanche of returned mail and can possibly bring a host to its knees. Beginning with V8.6 sendmail, a receipt is sent when the mailing list is first expanded, and the `Return-Receipt-To:` header is removed before forwarding the message to the list.

> Beginning with V8.7 sendmail, processing of all `Return-Receipt-To:` headers can be skipped by specifying `noreceipts` with the `PrivacyOptions` (`p`) option (see Section 34.8.47, PrivacyOptions (p)).

### 35.10.30 Sender:

The real sender

(RFC822)

> The `Sender:` header is like the `From:` header. But whereas the `From:` header shows the address of one sender, the `Sender:` header shows the address of the real sender. For example, an assistant can mail a letter for the boss using the boss's account. The boss's address is in the `From:` header, and the assistant's address is in the `Sender:` header. The syntax for the two is identical. Newer MUAs allow the user to create a custom `Sender:` header. The `Sender:` header should never be declared in the configuration file.

### 35.10.31 Subject:

Topic of the message

(RFC822)

> The `Subject:` header can be included in mail messages to give the topic of the message. Most user mail-reading programs display the arbitrary text that forms the field of this header when listing received messages. Although such text can legally extend over multiple indented lines, most mail-reading programs recognize only the first such line:

> >     Subject: About yesterday's meeting, I had some second
> >            thoughts about why the shape of the bonnet should
> >            remain so sharply curved at the ends.

> >        whitespace

> This would be displayed by the mailx(1) program in truncated form as:

> >     14   gw@wash.dc.gov Fri Aug  7 12:57  22/770 "About yesterday's meeting"

> The `Subject:` header is not used by sendmail, but it is often wrongly (albeit harmlessly) included in the configuration file:

> >     HSubject:             This actually does nothing

### 35.10.32 Text:

A synonym for Message:

(sendmail)

> The `Text:` header is the same as the `Message:` header. Both cause all lines that follow in the header portion of a mail message to be treated as message body.

> The `Text:` header should never be declared in the configuration file.

### 35.10.33 To:

The primary recipients

(RFC822)

> The `To:` header lists one or more of the recipients of the mail message. Other headers, such as `Cc:`, also list recipients.

> The sendmail program attempts to deliver a copy of the mail message to every recipient address that it can find in all the recipient headers and in the envelope. If the header of a mail message lacks recipient information (`To:`, `Cc:`, and `Bcc:` header lines), pre-V8.7 sendmail added an `Apparently-To:` header line and put the recipient's address from the envelope into the field of that header. Beginning with V8.7, the way a recipientless message is handled is determined with the `NoRecipientAction` option (see Section 34.8.43).

### 35.10.34 Via:

An unofficial trace header

(obsolete)

> The `Via:` header is not defined by RFC822 but occasionally appears in mail messages that sendmail needs to process. It is used by a few other networks to mark a mail message's transit through a forwarding host. It is an early, and now obsolete, version of the `Received:` header. The sendmail program counts the `Via:` header when determining the hop count but has no other use for it.

> The `Via:` header should never be declared in the configuration file.

### 35.10.35 X-Authentication-Warning:

Notification of security matters

(V8 sendmail)

> If the `PrivacyOptions` (`p`) option (see Section 34.8.47) is declared with `authwarnings`, V8 sendmail inserts a special header line for possible security concerns. That header line looks like this:

> >     X-Authentication-Warning: host: message

> Here, `host` is the canonical name of the host that inserted this header. The `message` is one of the following:

> Processed by user with `-C` file

>   An attempt was made by a user other than root to run sendmail with the `-C` command-line switch. That switch caused sendmail to read file in place of the system sendmail.cf file.

> user set sender to other using `-f`

>   A user or program's user identity used the `-f` command-line switch to change the identity of the sender to other (and user was not listed with the `T` configuration command). This can be legitimate when the user is uucp or daemon. It can also be legitimate when the user is sending to some mailing lists (see Section 22.8, "Security Features"). Such a warning can also indicate that someone is trying to forge mail.

> user owned process doing `-bs`

>   A user or program's user identity used the `-bs` command-line switch to make sendmail receive a mail message via its standard input/output using the SMTP protocol (and user was not listed with the `T` configuration command). This parallels network notification set up by defining IDENTPROTO when compiling sendmail and by use of the `$_` macro (see Section 31.10.1) in `Received:` headers.

> Processed from queue dir

>   A user other than root used the `-oQ` (or similar) switch (see Section 34.8.48, QueueDirectory (Q)) to process mail from a queue directory (dir) that was different from the one specified with the `QueueDirectory` (`Q`) option in the configuration file. The sendmail program can run as an ordinary user because this or some other command-line switch caused it to give up root privilege.

> Host name1 claimed to be name2

>   In the HELO message of an SMTP conversation the remote host name1 specified its canonical name as name2, and the two didn't match. This always indicates a problem. Either the remote host is misconfigured (a bad value in `$j`; see Section 31.10.20), the DNS maps for that host are wrong, or someone is trying to spoof the local sendmail.

> Host name didn't use HELO protocol

>   Every SMTP conversation for transfer of mail must start with the HELO (or EHLO) greeting. If, instead, a MAIL command was first, this header is inserted in the incoming message. The most likely cause of a missing HELO is the mistake of someone attempting to carry on an SMTP conversation by hand.

### 35.10.36 X400-Received:

Received via X400

(X400)

> The `X400-Received:` header is added by IDA sendmail to document receipt of a mail message from an X400 network. This header is used by both IDA and V8 to count the number of forwarding sites when computing the hop count of a mail message.

> The `X400-Received:` should never be declared in the configuration file.

35.9 Pitfalls |  | 36. The Command Line